QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940136.txt

Internet Message Format | 1994-11-13 | 12KB

Date: Sat,  2 Jul 94 04:30:01 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #136
To: tcp-group-digest


TCP-Group Digest            Sat,  2 Jul 94       Volume 94 : Issue  136

Today's Topics:
                  NetROM over Ethernet?  (Yuchhh...)
                            NOS and the PC
                        Stinkin PBBS (3 msgs)
                    Why not a solid PBBS program?

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri Jul 01 11:24 EDT 1994
From: "Ackermann, John" <[e-mail]>
Subject: NetROM over Ethernet?  (Yuchhh...)
To: tcp-group <[e-mail]>

We're trying to figure out the most expeditious way to build a fairly large
switch (2 64kb full duplex, 2 19.2kb half duplex, 3 9600, 1 1200 ports) and
it looks like no matter what we do we'll need two boxes to support all the
I/O.

One possibility is two NOS boxes.  Using ethernet to interconnect them seems
like a reasonable thing to do.

Can we attach netrom directly to an ethernet interface, or do we need to go
through the axip stuff to do it?

Thanks...

John   AG9V
[e-mail]

------------------------------

Date: Fri, 1 Jul 1994 18:36:33 -0700
From: Phil Karn <[e-mail]>
Subject: NOS and the PC
To: [e-mail]

I agree that DMA on the PC is an abomination that is best avoided
wherever possible. Not only is that particular implementation
especially bad, but much of the original economic and performance
rationale for DMA has also gone away as the technology has developed.
Fast CPUs, caches and cheap RAM are the most relevant developments.

Much of the original motivation for DMA was economic.  When memory was
expensive, you didn't want to dedicate it to buffering a device that
didn't get used all that often. You wanted to keep it general purpose.
DMA is basically a main memory multiporting scheme; if you don't need
a chunk of memory for a DMA buffer, you can use it to hold a program
or data.

The original idea behind DMA was to avoid the interrupt load and
latency that would otherwise occur with high speed I/O to and from
devices with little internal buffering (remember, memory was
expensive).  By transparently stealing memory cycles from the
processor, I/O could occur without involving the CPU in a lot of busy
waiting until the entire transfer was complete. The CPU could execute
other, unrelated tasks while the transfer continued.

But now that memory is cheap, you can move the "DMA buffer" to the
device itself; it's okay if it isn't used all that often. And this
buffer can be accessed by the CPU at its own speed; there's no need
for busy waits between transfers (ignoring wait states, etc).

There are other reasons to avoid DMA, even when it's reasonably well
designed.  The performance bottleneck in almost every modern
workstation and high performance (e.g., 486-class) PC is main
memory. That's why 486 processors have caches - so they can run faster
than main memory. But when a DMA device asynchronously accesses main
memory, the cache controller has to take great pains to ensure
cache/memory consistency. At a minimum, this means operating in a
write-through mode, giving up any cache gains on write operations. And
whenever a DMA device writes main memory, the cache controller must
ensure that any stale data in the cache is invalidated. Depending on
the cache design, this can significantly degrade performance.

Just to comment on one point you made:

  DMA :
  The PC's DMA controller is used to perform the transfer. The DMA controller
  performs a sequence of memory writes (using internal counters), but
  simultaneously drives signals to the card which act rather like an I/O read
  and provide a single byte in each operation. This halves the number of
  bus cycles used for the transfer, and requires no overhead from the CPU.


Actually, for modern CPUs I believe the number of ISA bus cycles is
the same.  In the CPU-driven transfer the data flows between CPU and
memory over a separate and much faster memory bus, so the ISA bus
remains the bottleneck. In fact, if you look at the end result the DMA
transfer often ends up consuming many more total bus cycles than the
CPU-driven approach because of DMA buffer placement restrictions that
often require the CPU to copy data between the DMA buffer and where it
really wanted it to go in the first place.

This is a problem particularly with 486s that have more than the 16
meg of memory that the ISA bus can address. If you happen to have a
program buffer above the 16 meg boundary, you have to first copy it
into a "bounce buffer" below 16 meg before you can DMA it (this is
common practice with DMA disk controllers like the Adaptec 1542B,
popular on UNIX systems).  And even when you have less than 16 meg,
bounce buffers are required if your original program buffer happens to
straddle a 64K physical boundary.

As for the two approaches (memory mapped and I/O mapped) used on
modern PC ethernet cards, they are probably equivalent in performance
because they are both limited by the ISA bus rate. However, the I/O
mapped approach is highly preferable, at least in real-mode systems,
because memory mapping can take up a good-sized chunk of upper address
space.

Phil

------------------------------

Date: Fri, 1 Jul 1994 08:08:35 -0500 (CDT)
From: [e-mail] (Steve Sampson)
Subject: Stinkin PBBS
To: [e-mail]

[e-mail] writes about what
[e-mail] writes:

>> I've been thinking of something like this. If everyone could get together
>> and write a good Amateur Radio PBBS program for Linux

> why isn't there a good, solid, NOS-based PBBS package available for hams who
> run DOS, Windows or OS/2 machines?

Gary L. Grebus writes:
> "Stamp out the PBBS in our lifetime."

Gary speaks pretty much the opinion of most people that have been around
packet radio for any length of time.  If you really want to bore someone to
death, have them buy a TNC and log into a PBBS for 10 days; then call the
coroners office for a pickup.  It's not something that gets better with age.
Just like the bulletin board in the lobby of schools and offices, nobody ever
reads it, but a lot of people stick things on it.

Probably the only intelligent thing I've read on the subject of transfering
information has to do with broadcast protocols.  For example, it seems criminal
that a PBBS would hand deliver copies to a circle of machines on the same
frequency (e.g., a satellite, or a town PBBS) when it could just broadcast the
information while the others listened.  The other really interesting article is
"The HUB 5/29 IP Routing Experiment" in the 12th ARRL Digital Conference.
Read this, and then decide whether your still interested in a boring PBBS.
Paul Overton and Ian Wade discuss a really nice routing scheme (only a mobile
user would complain I suspect - but TCP/IP isn't ready for mobile/portable
anyway) and then goes on to explain their modifications to NNTP that takes
advantage of this.  We've seen several automated IP routing schemes proposed,
but the truth is that Ham networks don't need them.  If you have more than 3
entries in your routing table, you should read this article.  I'd like to read
more about this system and maybe see a distribution for others to duplicate.

Basically I see no advantage of prolonging the PBBS given an operating network.
The lack of a network is the reason the PBBS exists today.  I think if towns
or communities developed along the lines of the HUB 5/29 article it would make
for a simple (easily duplicated) network scheme that could transport more
substantial mail or news articles. I know this will never happen in Oklahoma,
because there is no organization, but other communities should look into
this network and abandon the stupid PBBS, Rose, and Netrom.

--
Steve

------------------------------

Date: Fri, 01 Jul 94 15:55:24
From: [e-mail]
Subject: Stinkin PBBS
To: [e-mail]

> Gary speaks pretty much the opinion of most people that have been around
> packet radio for any length of time.  If you really want to bore someone
> to death, have them buy a TNC and log into a PBBS for 10 days; then call
> the coroners office for a pickup.  It's not something that gets better
> with age.

I couldn't agree more. However I think the real problem is the bulk of the
PBBS users are running DOS (or maybe even Windoze) and use a terminal
emulator or (terminal.exe) to log into their favorite PBBS. The machines are
probably 286's and the memory is 640k.
To answer Brian's question, the folks writting the 'really slick new"
software aren't running 286's with 640k and given its such an labor of love
to write this stuff they generally write it with the understanding that they
too will use it. If I am reading the sentiment right one won't find any more
DOS based xNOS's. There will be char based Lunix, or graphically based OS/2
or maybe even Windoze  based versions of tcp/ip suites that may not even
support AX.25 mailboxes nor netrom....I know mine won't.
Walt

------------------------------

Date: Fri, 01 Jul 1994 17:39:11 -0400
From: "Brandon S. Allbery" <[e-mail]>
Subject: Stinkin PBBS
To: [e-mail]

In your message of Fri, 01 Jul 1994 15:55:24, you write:
+---------------
| too will use it. If I am reading the sentiment right one won't find any more
| DOS based xNOS's. There will be char based Lunix, or graphically based OS/2
+------------->8

You won't be finding (m)any more DOS-based *servers*.  Clients can be darned
near anything; it's the SMTP/PBBS/convers/NNTP/etc. server hosts that are
crashing (sometimes literally) into the 640K limit all too regularly.

++Brandon
--
Brandon S. Allbery       kf8nh@44.70.4.88           [e-mail]
Friends don't let friends load Windows NT (tnx Sun)    A Linux iBCS2 developer
  The Witness (the Universe's biggest practical joker) is at it again... who
  else would pit the U.S. soccer team against Brazil on the Fourth of July?!

------------------------------

Date: Fri, 1 Jul 1994 18:56:55 -0700
From: Phil Karn <[e-mail]>
Subject: Why not a solid PBBS program?
To: [e-mail]

>  Perhaps it would take a commercial venture to do it right. Would a PBBS
>SysOp, who's spent maybe $1000-$2000 (or more) on radios, TNCs, antennas,
>PCs, etc, also shell out maybe $50-$100 or so for GOOD software that beats
>the heck out of the standard freebie AX.25 PBBS packages or the bazillion
>semi-complete NOSs floating around?

Why do we have to have PBBSes at all, especially if we're using
TCP/IP?  Why do hams have to keep reinventing the wheel, especially
ones that aren't quite round? What's wrong with just using all the
mail and news software that the rest of the Internet uses that seems
to work fine for them? Why do hams always have to be different?

Phil

------------------------------

End of TCP-Group Digest V94 #136
******************************